Field
Embodiments of the invention provide a client authentication mechanism for user processes and web services present on a common host. More specifically, a local process may be authenticated based on a self-signed certificate and a logged-in context of the user executing the process. Doing so avoids requiring the user from having to explicitly provide either login credentials or a trusted third-party certificate.
Description of the Related Art
A variety of techniques are used to provide access to computing resources and applications. For example, enterprise applications are frequently exposed to clients using web services. Web services allow users to access an enterprise application using a web browser, which passes HTTP requests to the web service and renders the resulting responses. For example, REST (Representational State Transfer) is a stateless architecture which runs over HTTP. REST defines an architecture to present enterprise applications as a series of web pages. XML-RPC and SOAP provide other examples of web services frameworks used to expose enterprise computing applications using a web browser
One common issue for web services is that an enterprise application needs to ensure that only authorized users and processes can access the computing resources exposed by a web service. For example, a REST application can require a user to provide access credentials to access a web service, such as a user name and password. Another approach is to provision a certificate on the both the client and server and to perform a mutual authentication using the certificates (e.g., establishing a mutually authenticated SSL session). This approach needs the web service to trust a signature included in the client certificate and requires that the certificate provisioned on the client be managed over a certificate lifecycle.
In some cases, a local process may want to access a web service exposed on a server. For example, an enterprise may deploy a script or other command line interface (e.g., a command line interface shell) on a server hosting the web service. The local process may invoke functions exposed by the web service (e.g., by invoking REST APIs). To do so, the local process needs a mechanism to authenticate itself to the web service. However, the local process may not have an interface for the client to enter a username and password or have a certificate issued by a trusted third-party certificate authority.
Further, a user interacting with a command line interface may have already been authenticated by the server hosting both the web service and the local application. In such cases, it is generally preferable to not ask a user to continually provide authentication credentials. Further still, in some cases, a user may wish to initiate a local process (e.g., as a script or regularly scheduled job) and not monitor the execution thereof. In such a case, the user does not want to monitor the execution of the local process simply to provide authentication credentials when the script accesses the web service.